Para llegar al diseño de un TDA se tienen dos caminos: uno que va de lo
general a lo particular y de lo particular a lo general. Uno no es mejor que el
otro, pero la mayoría de las obras de computación han privilegiado el enfoque de
lo general a lo particular, por su caracter análitico; sin embargo, en la
práctica muchos TDAs nacen como algo de aplicación particular para convertirse
en algo general.
Cuando se parte de lo general a lo particular, con frecuencia se está
diseñando una aplicación compleja y se ve toda la aplicación como un unico TDA.
Por ejemplo el TDA Contabilidad, representa toda la aplicación y sus operaciones
representan operaciones de alto nivel. El siguiente paso es desglosar este TDA,
en este caso es fácil, porque una contabilidad está compuesta de cuentas y
transacciones. Las cuentas son TDAs y las transacciones son operaciones del TDA.
Se puede coger el TDA Cuenta y ver que está compuesto a su vez de TDAs. El
proceso se aplica repetidas veces, pero ¿Cúando terminar?, cuando se encuentren
los tipos base del lenguaje que se está usando, o sea, cuando se encuentren los
enteros, los flotantes, los arreglos. etc. Esta forma de proceder asegura un
alto grado de generalidad en la aplicación pero no en los TDA, porque estos se
aplican a un sólo software. Como ya vimos, el uso de un TDA en varias
aplicaciones asegura su generalidad, que no es el caso de la Contabilidad.
Pero cuando se hace la siguiente aplicación por este método se descubre que
al hacer el diseño de algunos TDAs, estos son muy parecidos. Entonces, lo que se
hace es generalizar estos TDAs, realizando un proceso inductivo: de unos pocos
casos se concluye la generalidad, es un proceso que va de lo particular a lo
general. Como se ve, en el desarrollo de software no se usa un solo método, sino
que los dos se entremezclan y son casi inseparables.
De todos modos siempre es mejor diseñar los TDAs con el mayor grado de
generalidad que se pueda, para ello podemos tener en cuenta los siguientes
concejos:
- Diseñe el TDA usando el lenguaje de la realidad que se modela. Tenga el
cuenta los términos que se utilizan, o sea el nivel léxico; la forma en como
esos términos pueden combinarse y estructurarse, el nivel sintáctico; el
significado de los terminos y de las estructuras del lenguaje, o sea el nivel
semántico y finalmente vea cómo se relaciona esa realidad con otras
inmediatamente cercanas y en especial como las personas lo usan, en el
contexto, es decir, el nivel pragmático.
- Trate de ver cuales son las operaciones verdaderamente atómicas, las que
no pueden hacerse en términos de otras. Las otras, las moleculares, no deben
incluirse en su diseño a menos que sean muy usadas.
- Cuando hay dos operaciones parecidas trate de unirlas en una sola usando
parámetros, pero eso sí, no fuerce la situación, sólo cuando sea natural, esto
es, que se corresponda a la realidad que está modelando.
- Trate de hallar categorías generales, esto es, TDAs que se puedan derivar
de otros, como por ejemplo un vehículo de pasajeros es un tipo de vehículo,
siendo este último un TDA más general. No quiere decir que deje este último,
más bien se sugiere usar el mecanismo de la herencia para establecer una
jerarquia de conceptos con distinto nivel de generalidad.
- Mire si ya ha diseñado TDAs parecidos y vea si es posible que sean los
mismos y en este caso vuélvalos uno solo. Pero cuidado, procure siempre
conservar la consistencia con la realidad, no convierta a un perro en un gato.
- Cuando diseñe un TDA trata que la interfaz, el conjunto de operaciones,
sea lo más general posible, esto se logra haciendo que las operaciones no
dependan de la implementación. Estos se logra diseñando con TDA y no pensando
tanto en los elementos del lenguaje en el que se vaa implementar. La medida
del exito de da cuando se cambia la implementación de un TDA por otro y no es
necesario cambiar nada en los programas que usen el TDA.
Recuerde que
los TDAs deben ser una ayuda y no una carga adicional.
Next: Resumen Up: 1. El Tipo de Previous: 1.5.3 Uso Contents
